I am learning flutter from JustAcademy, They provide very much great environment where people gather and work simultaneously. totally project based training institute.
Awesome Experience. I am a Front-end Web Designer working at Star India for 3 years now. I applied for Full-stack development and my experience has been phenomenal & they really do help with placements exceptionally. Thank you Roshan sir so much.
Selenium Training in Mumbai | Selenium Online | Mobile App Testing Using Appium Training in Mumbai | Appium Online | Register for a Free Demo | Download Brochure
Selenium remains the most widely used web automation testing tool in the world and is assessed in virtually every QA automation interview in India in 2026. Whether you are a fresher appearing for your first automation testing role or an experienced manual tester transitioning into automation, mastering Selenium WebDriver concepts and being able to answer selenium interview questions confidently is the single most important preparation step you can take.
This blog covers the most asked selenium webdriver interview questions and answers for freshers and experienced candidates, organized from foundational concepts to advanced framework and tool-specific topics. Every question is numbered for easy navigation so you can study systematically, identify gaps in your knowledge, and track your preparation progress. Whether you are building your skills through the best Selenium course in Mumbai or through a live interactive online QA automation training program, this guide gives you complete coverage of what interviewers consistently ask in 2026.
Selenium is an open-source automation testing framework used to automate web browser interactions. It allows QA engineers to write scripts in multiple programming languages including Java, Python, C#, and JavaScript that control a browser programmatically to simulate user actions like clicking buttons, filling forms, navigating pages, and validating displayed content. Selenium is primarily used for functional regression testing of web applications, cross-browser compatibility testing, and as the foundation for larger test automation frameworks. Its open-source nature, multi-language support, and cross-platform compatibility have made it the industry standard for web automation testing globally and particularly in the Indian QA job market.
Selenium consists of four main components. Selenium WebDriver is the core component that provides a browser automation API allowing direct communication with browsers through browser-specific drivers. It is the foundation of modern Selenium automation projects. Selenium IDE is a browser extension available for Chrome and Firefox that records and replays user interactions for quick test script generation, primarily used for prototyping and simple automation scenarios. Selenium Grid enables distributed test execution across multiple machines and browsers simultaneously, reducing execution time through parallel testing. Selenium RC, which stands for Remote Control, is a legacy component that has been superseded by WebDriver and is no longer actively used in modern projects.
Selenium WebDriver supports multiple programming languages through official client libraries. These include Java, which is the most widely used language for Selenium automation in India, Python, C#, JavaScript with Node.js, Ruby, and Kotlin. Java is the preferred choice in the Indian QA industry because of its strong enterprise adoption, the maturity of the Java testing ecosystem including TestNG and Maven, and the large number of job postings that specify Java Selenium skills. Python is the second most commonly used language for Selenium automation due to its simpler syntax and growing popularity in QA teams.
Selenium WebDriver supports all major browsers through browser-specific driver executables. Chrome is supported through ChromeDriver, Firefox through GeckoDriver, Edge through EdgeDriver, Safari through SafariDriver which is built into macOS, and Internet Explorer through InternetExplorerDriver for legacy applications. Each browser driver translates WebDriver API calls into browser-specific instructions. From Selenium 4 onwards, Selenium Manager automatically manages driver downloads and updates, eliminating the need to manually download and configure driver executables. Chrome is by far the most commonly used browser in Selenium automation projects in India.
Selenium 4 introduced several significant improvements over Selenium 3. The most important change is the adoption of the W3C WebDriver standard as the communication protocol, replacing the JSON Wire Protocol used in Selenium 3. This provides more consistent behavior across different browsers. Selenium 4 introduced Selenium Manager for automatic driver management, Chrome DevTools Protocol integration for advanced browser control, relative locators for finding elements relative to other elements, improved Selenium Grid with better scalability and Docker support, and a new Grid UI. The Actions class was also updated in Selenium 4 with a new fluent API for building complex interaction sequences.
WebDriver is an interface in Selenium that defines the methods for controlling a browser. Each browser has a specific driver class that implements the WebDriver interface, such as ChromeDriver for Chrome and FirefoxDriver for Firefox. When a test script creates an instance of ChromeDriver, Selenium Manager or a manually configured driver executable starts a ChromeDriver server process that communicates with the Chrome browser using the W3C WebDriver protocol over HTTP. The test script sends commands like navigate to URL or click element to the driver, which translates them into browser-specific instructions and returns results to the script.
Both driver.get() and driver.navigate().to() open a URL in the browser and wait for the page to load completely before returning control to the script. The practical difference is that driver.navigate() provides additional navigation methods that driver.get() does not. driver.navigate().back() simulates clicking the browser back button. driver.navigate().forward() simulates clicking the browser forward button. driver.navigate().refresh() refreshes the current page. For simply loading a URL, both methods are functionally equivalent. driver.navigate().to() is typically used when browser history navigation is also required in the same test.
driver.getTitle() returns the title of the current web page as displayed in the browser tab. driver.getCurrentUrl() returns the complete URL of the current page including protocol, domain, path, and query parameters. driver.getPageSource() returns the complete HTML source code of the current page as a string. In test assertions, getTitle() and getCurrentUrl() are commonly used to verify that navigation has reached the expected page. getPageSource() is used when you need to search for text or patterns in the raw HTML rather than through rendered WebElements, though this is generally less preferred than finding specific elements.
isDisplayed() returns true if the element is visible on the page, meaning it is rendered and has dimensions greater than zero. It returns false for elements that exist in the DOM but are hidden through CSS display none or visibility hidden. isEnabled() returns true if the element is enabled and can be interacted with, and false for disabled form elements like read-only input fields or disabled buttons. isSelected() returns true for elements that have a selected state, specifically checkboxes that are checked, radio buttons that are selected, and option elements in a select dropdown that are currently selected. Using the wrong method for a specific assertion is a common beginner mistake that interviewers test for.
Text is entered into an input field using the sendKeys method on a WebElement. First, the input element is located using an appropriate locator. Then sendKeys is called with the text to be entered as a parameter. To clear any existing text before typing, the clear method is called before sendKeys. For special keyboard keys like Enter, Tab, or function keys, the Keys enum provides constants that can be passed to sendKeys alongside or instead of text. For example, Keys.ENTER simulates pressing the Enter key, Keys.TAB moves focus to the next field, and Keys.chord(Keys.CONTROL, "a") selects all text in the field.
The click method is called on a WebElement to simulate a mouse click. The element is first located using a locator, then click is called on the returned WebElement object. For links specifically, click navigates to the href URL. For buttons, click triggers the button action. If the element is not visible or not in the viewport, it may need to be scrolled into view first using JavaScript executor before clicking. For scenarios where the standard click is intercepted by an overlay, a JavaScript click using executeScript with the arguments[0].click() expression is used as a workaround, though this should be used sparingly as it bypasses real user interaction simulation.
getText() returns the visible inner text of a WebElement, excluding HTML tags and hidden text. It is used to retrieve the displayed content of elements like paragraphs, headings, labels, table cells, and error messages for use in assertions. getText() returns an empty string for elements that are not displayed. It trims leading and trailing whitespace from the returned text. A common interview question asks the difference between getText() and getAttribute("value"). getText() returns the visible text content of the element while getAttribute("value") retrieves the value attribute, which is used for form input fields that display their current value through the value attribute rather than inner text.
getAttribute() returns the value of a specified HTML attribute of a WebElement. It is used to retrieve values that are not visible as element text, such as the value attribute of input fields, the href attribute of links, the src attribute of images, the class attribute for CSS classes, the placeholder attribute for input hints, and custom data attributes. If the specified attribute does not exist on the element, getAttribute() returns null. Interviewers commonly ask candidates to explain how they would verify the URL of a link, which is done using getAttribute("href"), or how they would get the current value of an input field, which is done using getAttribute("value").
JavascriptExecutor is an interface in Selenium that allows JavaScript code to be executed directly in the browser context from within a test script. It is used for scenarios that Selenium WebDriver cannot handle directly, such as scrolling the page to bring an element into view, clicking elements that are overlapped by other elements, modifying element attributes or styles, handling HTML5 features, and interacting with elements in complex shadow DOM structures. The executeScript method takes a JavaScript string and optional WebElement arguments. While JavascriptExecutor is a powerful workaround, it should be used sparingly because it bypasses the real user interaction simulation that makes Selenium tests meaningful.
driver.close() closes only the currently active browser window or tab but keeps the WebDriver session alive. If the test has opened multiple windows, the other windows remain open and the driver can continue interacting with them after switching to another window handle. driver.quit() terminates the entire WebDriver session, closes all browser windows opened during the session regardless of how many are open, and releases all system resources including the browser process and driver process. In test teardown methods, driver.quit() should always be used to ensure complete cleanup. Using driver.close() in teardown instead of driver.quit() is a common mistake that can leave orphaned browser processes consuming memory on the test machine.
Selenium WebDriver provides eight locator strategies for identifying elements. ID locates an element by its unique id attribute and is the fastest and most reliable locator when available. Name locates an element by its name attribute, commonly used for form fields. ClassName locates elements by a single CSS class name. TagName locates elements by their HTML tag such as input, button, or a. LinkText locates anchor elements by their exact complete visible text. PartialLinkText locates anchor elements by a partial match of their visible text. CSS Selector uses CSS syntax to target elements by attributes, classes, IDs, and relationships. XPath uses XML path expressions to navigate the DOM and is the most powerful and flexible locator strategy.
A good locator is unique, meaning it identifies exactly one element on the page. It is stable, meaning it does not change between page loads or application updates. It is readable, meaning other team members can understand what element it targets. And it is fast, meaning it does not require extensive DOM traversal to resolve. Best practices include preferring ID and name locators when they are unique and stable, using CSS selectors for most other scenarios because they are faster and more readable than XPath, avoiding locators based on absolute XPath expressions that include the full path from the root, avoiding locators based on auto-generated attributes that change frequently, and using data-testid or custom testing attributes added by developers specifically for test automation when available.
A CSS selector targeting an element by an exact attribute value uses the syntax element[attribute='value']. For example, input[type='submit'] targets input elements with type equal to submit. For partial attribute matching, the contains operator uses element[attribute*='partial'] syntax. The starts-with operator uses element[attribute^='prefix'] and the ends-with operator uses element[attribute$='suffix']. Combining multiple conditions is done by chaining: input[type='text'][placeholder='Email'] targets input elements with both type text and placeholder Email. CSS selectors are generally faster than XPath and preferred for most locator scenarios in Selenium automation.
XPath for dynamic elements uses functions that perform partial matching rather than exact attribute values. The contains function targets elements where an attribute contains a specified substring, for example //input[contains(@id,'username')]. The starts-with function targets elements where an attribute begins with a specified value. The text function locates elements by their visible text content, for example //button[text()='Submit']. The normalize-space function handles elements where text content has variable whitespace. Axes like parent, ancestor, following-sibling, and preceding-sibling allow navigation relative to known stable elements when the target element itself has no reliable stable attributes. Combining multiple conditions with and and or provides further precision for complex scenarios.
Implicit wait instructs WebDriver to wait for a maximum specified duration when attempting to locate an element before throwing a NoSuchElementException. It is set once on the driver instance and applies globally to every findElement call for the lifetime of the driver session. The main limitations of implicit wait are that it applies uniformly to all element lookups regardless of whether a wait is actually needed, which can slow down tests unnecessarily. It interacts unpredictably with explicit waits when both are used together, creating inconsistent behavior. It cannot wait for specific conditions like element visibility or clickability. And it does not provide fine-grained control over the wait behavior for individual interactions. For these reasons, explicit waits are preferred over implicit waits in professional automation frameworks.
Explicit wait pauses test execution until a specific condition is met or a timeout expires. It is implemented using the WebDriverWait class combined with ExpectedConditions. WebDriverWait is initialized with the driver instance and a timeout duration. The until method accepts an ExpectedConditions expression that defines the condition to wait for. Common ExpectedConditions include visibilityOfElementLocated which waits for an element to be visible, elementToBeClickable which waits for an element to be visible and enabled, presenceOfElementLocated which waits for an element to exist in the DOM regardless of visibility, textToBePresentInElement which waits for specific text to appear, and alertIsPresent which waits for a JavaScript alert. Explicit wait is preferred because it is precise, applied to specific interactions, and does not interfere with the rest of the test.
StaleElementReferenceException occurs when a WebElement reference that was previously located becomes stale, meaning the element it referenced no longer exists in the DOM or has been replaced by a new DOM element. This commonly happens after page navigation, page refresh, dynamic content updates like AJAX reloads, or interactions that cause the DOM to be rebuilt. The standard handling approach is to re-locate the element after the DOM update by calling findElement again rather than reusing the stale reference. Implementing a retry mechanism that catches StaleElementReferenceException, waits briefly, and re-locates the element is a common framework-level solution for scenarios where stale elements occur frequently due to dynamic content.
NoSuchElementException is thrown by Selenium when findElement cannot find an element matching the specified locator in the current DOM. Common causes include an incorrect locator that does not match any element, the element not yet existing in the DOM because the page or dynamic content has not finished loading, the element being inside a frame that has not been switched into, a spelling or syntax error in the locator expression, and the element existing in a different context such as a shadow DOM that requires special handling. Resolving this exception involves verifying the locator in the browser developer tools, adding an appropriate explicit wait to ensure the element is present before locating it, and checking whether frame switching is required.
Custom dropdowns built with div, ul, li, or span elements rather than native HTML select elements cannot be handled with the Selenium Select class. The standard approach is to first click the dropdown trigger element to open the options list, then locate the desired option element using an appropriate locator based on its visible text or data attribute, and click it to make the selection. If the options list is long and the desired option is not immediately visible, scrolling within the dropdown container using Actions or JavaScript may be required before clicking. A reusable helper method that accepts the dropdown trigger locator and the desired option text as parameters is a common Page Object pattern for handling custom dropdowns.
For file upload inputs that use the standard HTML input element with type file, the file path is sent directly to the input element using sendKeys with the absolute path of the file to be uploaded. This works because sendKeys on a file input element sets its value to the specified file path, triggering the file selection. The file upload dialog is handled by the operating system and cannot be controlled by Selenium WebDriver directly for non-input-based dialogs. For upload scenarios that open a native OS file dialog through a non-input mechanism, tools like AutoIt on Windows or third-party libraries are used alongside Selenium to interact with OS-level dialogs.
Right-click and double-click operations are performed using the Actions class. For right-click, the contextClick method is called on the Actions object with the target element as a parameter, followed by a call to build and perform. For double-click, the doubleClick method is used in the same pattern. The Actions class provides a fluent API where multiple actions can be chained together before calling perform to execute them all in sequence. For example, a right-click followed by selecting an option from the context menu would chain contextClick on the target element, pause briefly, and then click the menu option element.
Scrolling in Selenium can be performed in multiple ways. Using JavascriptExecutor, the scrollIntoView JavaScript method scrolls a specific element into the visible viewport. The scrollBy method scrolls the page by a specified number of pixels in the X and Y directions. The scrollTo method scrolls to absolute coordinates. In Selenium 4, the Actions class provides a scrollToElement method that scrolls the element into view using the W3C standard scroll mechanism. In Selenium 4, the new scrollByAmount and scrollFromOrigin methods in the Actions class provide more precise scroll control for complex scenarios like infinite scroll pages and virtualized lists.
Screenshots in Selenium are taken using the TakesScreenshot interface. The driver is cast to TakesScreenshot and the getScreenshotAs method is called with OutputType.FILE or OutputType.BYTES to capture the current browser view. The resulting file is then copied to a desired location using FileUtils.copyFile from the Apache Commons IO library. Screenshots are typically captured in the test framework's failure listener so that a screenshot is automatically saved whenever a test fails, providing visual evidence of the failure state. Screenshots of specific elements rather than the full page are taken using the same getScreenshotAs method called on a WebElement rather than the driver.
SSL certificate errors occur when a browser encounters an invalid, self-signed, or expired SSL certificate and displays a security warning page instead of the target application. In Selenium, this is handled by configuring the browser options before creating the driver instance. For Chrome, ChromeOptions with the setAcceptInsecureCerts capability set to true or the ignore-certificate-errors argument instructs ChromeDriver to bypass SSL warnings. For Firefox, FirefoxOptions with setAcceptInsecureCerts set to true achieves the same result. This configuration is typically applied in the base test setup so that it applies to all tests in the framework that run against environments with self-signed certificates, which is common in development and staging environments.
findElement returns the first WebElement that matches the specified locator and throws NoSuchElementException if no match is found. It is used when you expect exactly one matching element and want to interact with it directly. findElements returns a List of all WebElements matching the locator and returns an empty list rather than throwing an exception if no matches are found. It is used for counting elements, iterating over collections of similar elements like table rows or list items, checking whether an element exists without the risk of an exception, and extracting text or attributes from multiple elements simultaneously.
Page Object Model is a design pattern where each web page or significant section of the application is represented by a dedicated Java class. The page class contains WebElement declarations for the elements on that page and methods that represent the actions users can perform on those elements. Test scripts use the page object methods rather than directly interacting with WebDriver and locators. POM is considered a best practice because it separates test logic from page structure, making tests more readable and less dependent on implementation details. When the UI changes, only the affected page object class needs to be updated rather than every test that interacts with that page, dramatically reducing maintenance effort.
Page Factory is a Selenium support class that provides an annotation-based implementation of the Page Object Model. WebElement fields in the page class are annotated with FindBy, which specifies the locator strategy and value. The PageFactory.initElements method is called in the page class constructor with the driver instance to initialize all annotated fields with lazily evaluated WebElement proxies. When a method accesses an annotated field, the element is located in the DOM at that moment. FindAll annotation finds multiple elements matching the locator and FindBys annotation applies multiple locator conditions. Page Factory reduces the boilerplate of calling findElement for each element declaration but has limitations with dynamic elements and is not preferred by all teams for complex applications.
A hybrid framework combines elements of multiple framework types to leverage the strengths of each. The most common hybrid approach in Selenium automation combines the data-driven framework, which reads test data from external sources like Excel, with the Page Object Model for UI abstraction, keyword-driven concepts for reusable action methods, and TestNG for test execution and reporting. A well-designed hybrid framework provides separation of test data from test logic, reusable page interactions, flexible test configuration, parallel execution support, and integrated reporting. Most professional Selenium frameworks in use at Indian companies in 2026 are some form of hybrid framework tailored to the specific needs of the application being tested.
TestNG is a testing framework for Java that provides structured test execution, configuration annotations, parallel execution, data provider support, and reporting. The key annotations used in Selenium TestNG projects are Test which marks a method as a test case, BeforeMethod which runs setup before each test such as launching the browser, AfterMethod which runs teardown after each test such as closing the browser, BeforeClass which runs once before all tests in the class, AfterClass which runs once after all tests in the class, BeforeSuite and AfterSuite for global setup and teardown, DataProvider which supplies test data for parameterized tests, and Parameters which injects values from the TestNG XML configuration file into test methods.
Data-driven testing in Selenium involves separating test data from test logic so that the same test scenario is validated against multiple data sets. The most common implementation uses TestNG's DataProvider annotation on a method that returns a two-dimensional array or an iterator of test data. The test method declares parameters matching the data types returned by the DataProvider. For reading data from external sources, Apache POI is used for Excel files and OpenCSV for CSV files. The DataProvider method reads each row of data and returns it as a test parameter set. The test method is then executed once for each row, with each execution receiving a different set of input values and expected results.
Cucumber is a BDD framework that integrates with Selenium to allow test scenarios to be written in plain English using Gherkin syntax. Feature files contain scenarios written with Given, When, and Then steps that describe the test in business language. Step definition classes contain Java methods annotated with Given, When, and Then annotations matching the Gherkin step text. Each step definition method calls the corresponding Selenium WebDriver actions through page object classes. The Runner class uses CucumberOptions to specify the feature file location, step definition package, and report plugins. Cucumber generates HTML reports that non-technical stakeholders can read. This combination of Cucumber and Selenium is widely used in Agile teams practicing BDD.
Parallel execution with Selenium Grid requires a running Grid hub and one or more registered nodes. In the test code, the RemoteWebDriver class is used instead of ChromeDriver or FirefoxDriver. RemoteWebDriver is initialized with the hub URL and the desired browser capabilities specified through ChromeOptions or FirefoxOptions. TestNG parallel execution is configured in the testng.xml file with the parallel attribute set to tests or methods and an appropriate thread-count. Each parallel thread creates its own RemoteWebDriver instance connected to the Grid hub, which routes the session to an available node with matching capabilities. This allows dozens of tests to run simultaneously across different browser and OS combinations.
AJAX calls load data asynchronously without full page reloads, meaning elements may appear, update, or disappear at unpredictable times. Handling AJAX content in Selenium requires explicit waits rather than fixed sleep statements. Common explicit wait conditions for AJAX scenarios include waiting for element visibility, waiting for specific text to appear in an element, waiting for an element to disappear such as a loading spinner, waiting for the number of elements matching a locator to change, and waiting for a JavaScript variable to reach a specific value using JavascriptExecutor. For complex AJAX scenarios, custom ExpectedConditions implementations allow waiting for any condition that can be expressed as a boolean Java expression.
Selenium Manager is a command-line tool included with Selenium 4 that automatically manages browser driver binaries. Before Selenium Manager, developers had to manually download the correct version of ChromeDriver, GeckoDriver, or other browser drivers that matched their installed browser version, add them to the system PATH or specify their location in code, and update them manually whenever the browser auto-updated. This was a frequent source of CI/CD pipeline failures when browsers auto-updated overnight. Selenium Manager automatically detects the installed browser version and downloads the matching driver if it is not already present, eliminating manual driver management and the version mismatch problems that caused intermittent failures.
Selenium has several important limitations that interviewers commonly ask about. It only supports web applications and cannot automate desktop or native mobile applications. It requires separate tools like Appium for mobile testing and AutoIt for desktop application testing. Selenium cannot handle CAPTCHA, as CAPTCHAs are specifically designed to prevent automation. It has limited built-in reporting capabilities and requires integration with TestNG, Allure, or ExtentReports for meaningful reports. Handling browser-level dialogs like file download dialogs, authentication prompts, and OS-level notifications requires workarounds. Selenium tests can be brittle when relying on poor locators or insufficient wait strategies. And Selenium does not provide built-in support for visual regression testing, which requires integration with tools like Applitools or Percy.
Both approaches refresh the current page but behave differently. driver.navigate().refresh() simulates pressing the F5 key to reload the page and maintains the browser history. driver.get(driver.getCurrentUrl()) navigates to the current URL as if it were a new page load, which clears the browser history for that page and does not trigger a true refresh event. For most testing scenarios, navigate().refresh() is the appropriate choice for simulating a page refresh. Getting the current URL and re-navigating is occasionally used when a true fresh navigation to the current URL is needed rather than a cached refresh.
Tooltips in web applications are typically implemented in two ways. HTML title attribute tooltips display the value of the title attribute as a native browser tooltip on hover. The title attribute value is retrieved using getAttribute("title") without needing to trigger the hover. CSS and JavaScript-based custom tooltips are elements that become visible when the user hovers over a trigger element. These are handled by using the Actions class to move to the trigger element with moveToElement, which triggers the hover state, and then locating and reading the tooltip element that appears in the DOM after the hover action.
Thread.sleep() is a Java method that pauses test execution for a fixed number of milliseconds regardless of whether the awaited condition has been met. It always waits the full specified time even if the element appears in one millisecond, wasting execution time and making tests slower than necessary. It is also unreliable because the chosen duration may be too short in slow environments. WebDriverWait polls for a specified condition at a configurable interval until the condition is met or the timeout expires. It returns as soon as the condition is satisfied rather than waiting the full timeout. WebDriverWait produces faster, more reliable tests and is the professional standard. Thread.sleep() should only be used as a last resort workaround when no reliable wait condition can be defined.
Console logs from the browser JavaScript console can be captured in Selenium using the LoggingPreferences class. ChromeOptions is configured with a logging preference that sets the browser log level to ALL. After navigating to a page or triggering actions that generate console output, driver.manage().logs().get(LogType.BROWSER) returns the collected log entries. For network request monitoring in Selenium 4, Chrome DevTools Protocol integration through the DevTools class allows capturing network events including requests, responses, and timing information. This is used in automation to verify that specific API calls are made, correct request payloads are sent, or performance budgets are not exceeded.
Browser cookies are managed through the driver.manage().getCookies(), addCookie(), getCookieNamed(), and deleteCookie() methods. getCookies() returns all cookies for the current domain as a Set of Cookie objects. getCookieNamed() retrieves a specific cookie by name. addCookie() adds a new Cookie object to the browser. deleteCookie() removes a specific cookie and deleteAllCookies() removes all cookies. Cookie manipulation is used in automation for bypassing login flows by injecting a valid session cookie instead of automating the login UI, verifying that the application sets required cookies with the correct values and expiry settings, and testing cookie-dependent functionality like user preferences and remember-me features.
DesiredCapabilities was the class used in Selenium 3 to specify browser and environment configuration for WebDriver sessions, including browser name, version, platform, and custom capabilities. In Selenium 4, DesiredCapabilities has been largely replaced by browser-specific Options classes like ChromeOptions, FirefoxOptions, and EdgeOptions, which provide a type-safe, IDE-friendly way to configure browser settings. The Options classes support all the capabilities that DesiredCapabilities provided plus browser-specific settings that were not available through the generic class. DesiredCapabilities is still used in some contexts, particularly for configuring RemoteWebDriver sessions with Selenium Grid when custom or non-standard capabilities are needed.
The isSelected() method on a WebElement returns true if a checkbox is currently checked or a radio button is currently selected, and false otherwise. Before checking the state, it is good practice to verify the element is displayed and enabled using isDisplayed() and isEnabled(). For test assertions, the expected state is compared against the value returned by isSelected(). For example, an assertion that a terms and conditions checkbox is unchecked by default verifies that isSelected() returns false before any user interaction. After clicking the checkbox, the assertion verifies that isSelected() returns true.
The Robot class is a Java standard library class that generates native OS-level keyboard and mouse events at the system level, outside the browser context. It is used for interactions that Selenium cannot handle because they occur at the operating system level, such as file upload dialogs, print dialogs, and Windows authentication prompts. Selenium's Actions class generates browser-level interactions within the browser window and is the standard approach for hover, drag and drop, keyboard shortcuts, and complex click sequences within the web application. Robot class is a last resort for scenarios where OS-level interaction is unavoidable. It is platform-dependent and can be fragile in CI/CD environments without display capabilities.
Headless testing runs the browser without a visible graphical interface, executing all browser operations in memory without rendering the browser window on screen. Chrome and Firefox both support headless mode through the addArguments("--headless") option in their respective Options classes. Headless testing is used in CI/CD pipelines on server environments that have no display server, to improve execution speed since rendering overhead is eliminated, and for running large numbers of parallel tests without consuming screen real estate. The limitation is that some CSS rendering, scroll behavior, and browser-window-dependent features may behave differently in headless mode compared to a visible browser, which can cause occasional test discrepancies that are absent in headed execution.
The most important best practices for Selenium test scripts include using the Page Object Model to separate element locators from test logic for maintainability. Using explicit waits with appropriate conditions rather than Thread.sleep for reliable synchronization. Writing independent tests that set up their own preconditions and do not depend on the state left by other tests. Using descriptive method names in page objects that reflect business actions rather than technical interactions. Keeping assertions in test methods rather than page object methods to maintain the single responsibility principle. Running driver.quit() in a finally block or AfterMethod to ensure browser cleanup even when tests fail. Avoiding hardcoded test data by using external data sources or constants. Committing all test code to version control and integrating the suite with a CI/CD pipeline for automatic execution on every build.
The most powerful preparation tool for Selenium interviews is a complete, well-structured automation framework project hosted on GitHub. A project that implements Page Object Model with Page Factory, TestNG for test execution and reporting, data-driven testing with Excel and DataProvider, Cucumber for BDD scenarios, Selenium Grid configuration for parallel execution, and Jenkins integration for CI/CD demonstrates the full range of skills interviewers assess. Having this project to reference in your interview transforms abstract knowledge into concrete demonstrated experience that is far more convincing than theoretical answers alone.
Many Selenium interviews include a live coding component where you are asked to write a locator for a given element, fix a broken test script, or implement a specific interaction like handling a dropdown or switching frames. Practicing writing Selenium code without IDE assistance, explaining your approach as you code, and debugging errors quickly under time pressure is essential preparation for these rounds. Working through real UI automation challenges on practice websites like the Selenium Playground or demo e-commerce sites builds the speed and confidence needed for live coding assessments.
Selenium involves multiple interconnected concepts including Java programming, WebDriver API, locator strategies, wait mechanisms, TestNG configuration, framework design, and CI/CD integration. Building a coherent, professional-level understanding of all these components through self-directed learning from scattered tutorials is difficult and time-consuming. Structured training with live instruction, integrated projects, and interview preparation focused on the types of questions covered in this blog produces significantly better results for both freshers and experienced candidates making the transition to automation.
JustAcademy's Selenium training programs cover every topic in this blog within a comprehensive curriculum that includes real-world automation framework projects, live doubt resolution, mock interviews, and placement support tailored to the Indian QA job market.
For professionals and freshers in Maharashtra who prefer hands-on classroom learning with local industry connections, Selenium Training in Mumbai is widely recognized as the best Selenium course in Mumbai for building complete interview-ready automation skills. For learners anywhere in India or globally, Selenium Online Training delivers the same fully live and interactive curriculum with placement support from any location.
For QA professionals who want to extend their automation skills into mobile testing, JustAcademy also offers:
Building skills across adjacent technologies makes you a more versatile and competitive QA automation professional. Explore these programs at JustAcademy:
The most asked Selenium interview questions for freshers span every dimension of what interviewers assess, from WebDriver fundamentals and locator strategies to wait mechanisms, framework design, TestNG configuration, Cucumber BDD integration, and professional best practices. The fifty questions covered in this blog give you a comprehensive study resource that addresses both the conceptual and applied dimensions of Selenium automation testing.
Strong Selenium knowledge for interviews is built through a combination of thorough conceptual preparation and substantial hands-on practice. Understanding why explicit waits are used rather than Thread.sleep is as important as knowing the syntax. Knowing how to implement Page Object Model is as important as being able to explain why it reduces maintenance effort. Preparing both dimensions puts you in the strongest possible position for any Selenium interview in India in 2026.
The fastest and most reliable path to that preparation level is through structured training that covers Selenium within a full QA automation context, includes live project work building complete frameworks, and prepares you with mock interviews and placement support that connect your skills directly to the job market.
For learners in Maharashtra who want the best Selenium training in Mumbai with classroom-based learning and direct access to the Mumbai QA hiring market, Selenium Training in Mumbai is the program built for exactly that outcome. For learners across India and globally, Selenium Online Training delivers the same live interactive curriculum and placement support from wherever you are.
Register for a Free Demo to experience the training firsthand and speak with an advisor about your Selenium interview preparation goals, or Download the Brochure to review full course details, batch schedules, and fees before you decide.
Selenium WebDriver Interview Questions and Answers for Freshers and Experienced Testers in 2026
UI UX Interview Questions and Answers for Freshers and Beginners Covering Design Thinking, Figma, Wireframing, and UX Research in 2026
Figma Interview Questions and Answers for UI UX Designers, Freshers, and Experienced Designers in 2026
SQL, ORM, and Database Interview Questions and Answers for Python Backend Developers and Freshers in
OOP Concepts, Python Classes Interview Questions and Answers for Beginners and Freshers in 2026
REST API, FastAPI, and Django REST Framework Interview Questions and Answers for Python Freshers and Developers in 2026
Flask API, Python Backend Interview Questions and Answers for Beginners and Freshers in 2026
Django Interview, Python Backend Questions and Answers for Freshers and Beginners in 2026
Python DSA, Coding Interview Questions and Answers for Freshers and Beginners in 2026
Version Control, GitHub Interview Questions and Answers for Python Developers and Freshers in 2026
